I propose we manage this RFC under the process suggested by this RFC.

I have a feeling that in some cases a non-biased Shepherd team has a risk of not being able to reach unanimity. SC stepping in might not have a consensus about the outcome either. Should this be explicitly mentioned as grounds for an explicit «postpone» decision?

I'm generally of the inclination that we should avoid front-loading process decisions as much as possible... If we're treating the steering team as having meta-responsibility for ensuring this process works maybe we should just leave it open for them to step in and make necessary callls (and propose necessary formal adjustments) if the process is not meeting its intended outcomes?
I think when the process has a clear potential for a deadlock, it is good both to create more chances to avoid the deadlock after discussion, and to prepare a clear path of recognition of a deadlock. After all, we already know we are bad at this recognition.

Fair. Can you recommend a specific patch?

A slightly parenthetical issue (but relevant since we should avoid having too much bureaucracy) is whether the nix-core team (https://github.com/NixOS/rfcs/blob/master/rfcs/0025-nix-core-team.md) is still necessary under the new RFC process. Its main purpose was evaluating Nix changes and getting proposals unstuck, but that's also covered by this PR.

IMHO, (a) and (b) can and should either cause this RFC to go to Refine Idea, or those be added through RFC that amend this one. I strongly suggest going through RFCs, either one for both, or one per. One per is probably better for the fact that issues with either of the proposed amendments will not block the other, but at the same time, could cause RFC fatigue.

(Opinion is in bold only to make it obvious.)

@vcunat both (a) and (b) are currently left as future work as I understand it:

Define how the Steering Committee is picked in the future and how to replace members thereof if they are not able to participate in the meetings, including guidelines on when to replace members. (a timeline, not being active, etc.)

@domenkozar My opinion is summed up at #36 (comment). Honestly, if you feel like this is important, I think we should interrupt the FCP, discuss the ideas, amend the RFC and trigger a new FCP. I'd guess if the rate of discussion is as active as it is currently being, this would delay the merging of this RFC by 2-3 weeks. However, I am personally neutral on this question.

An alternative option would be to define the RFC process for other RFCs before this RFC is merged (and the RFC process is actually formally defined), and consider that when the current FCP ends (ie. in a few days) the current state of this RFC should be used to handle other RFCs, until this RFC is finalized and merged, at which point the merged RFC will become reference.

This way:

• This RFC handles all the cases
• We actually abide by “However, sometimes substantial new arguments or ideas are raised, the FCP is canceled, and the RFC goes back into development mode.” -- I think @domenkozar's argument can be considered substantial, but as it is currently explicitly left as future work there is room for debate about whether it is new
• Other RFCs can move forward in the mean time.

Deciding to go this way would require approval of the Steering Committee, though, given it will affect how all RFCs are handled until this RFC is merged.

If the Steering Committee is in favor of this, I am in favor of cancelling the FCP and polishing this RFC. Otherwise, I think this RFC should continue its way forward so that we have an agreed-upon basis, but will not try to defend this thought should anyone strongly want to examine these ideas (because of the aforementioned sentence in the RFC text about “substantial new ideas”)

Currently the FCP is ticking, so absent answer of the Steering Committee agreeing to this idea or someone expressing strong will to examine these ideas within the context of this RFC (and not subsequent ones), if the FCP runs to its end this RFC will be approved.

I have only seen Python proposal two days ago otherwise I'd be happy to flag myself as slow to respond in this particular case.

If we're building rules for the next few years, I'd say 2-3 weeks is a minor bump and is expected - otherwise what's the point of RFC process having FCP be broadcasted? RFC process has substantial overhead though - we need another meeting of steering committee, pick shephard team again, etc. At the end it's going to be more work.

Honestly, if you feel like this is important, I think we should interrupt the FCP, discuss the ideas, amend the RFC and trigger a new FCP

I'm still +0 to address these - @shlevy raised a valid point that this is a bigger issue for nixos foundation than the steering committee itself.

Shephards should vote if my concern is valid (maybe the process needs to be amended how FCP can actually be "canceled, and the RFC goes back into development mode"?).

@Ekleog Not sure I understand, are you proposing that we start using the steering/shepherd model for other RFCs now before this one is merged, and in the mean time take this one out of FCP to visit the issues @domenkozar raises? If so, I'd personally prefer we get this one in and spend the polishing time on a separate amendment RFC, but I'm willing to participate in steering team work if we decide to go that route.

(Note that the "personal preference" above only applies if people are anxious about getting started shepherding soon. I'm personally fine with this taking longer as well).

@domenkozar The FCP being cancelled, in my understanding, just means that we do like it never existed, it doesn't mean that the RFC is rejected and starts from scratch.

As for shepherds voting, a single shepherd willing to stop the FCP can do it, so there is no need for a vote (as entering the FCP is made by unanimity, it is logical that leaving it can be done by a single person, as the idea is that the end result must be unanimous).

Currently, my reading is @samueldr is -1, and I am -0 (and ready to switch to +1 should someone voice a strong desire to discuss these now and not in amendment RFCs)

@shlevy That's exactly what I am saying indeed, as an alternative to either going the amending-RFC or the second-FCP route. Without a strong preference for this new idea either, but I wanted to point out that we could still handle @domenkozar's concerns now while not delaying further pending RFCs.

@domenkozar I would rather us go forward at this point. The RFC is clear enough for me to follow as a process. I don't think that it needs to be treated like a legal document. Now the next thing to do is to actually do the work and exercise that process and then we can adjust it with real data.

The 10 days period has elapsed with no major disagreement. Declaring the @NixOS/rfc-steering-committee to be official!

Now some of the «future work» can start without creating confusion.

Does anyone want to start the discussion (on Discourse, probably?) about long-term plans for SC composition update rules, or should I start something then see where it goes?

Should this discussion include the Foundation positions too?

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/new-rfc-50-merge-bot-for-maintainers/3795/1

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/new-rfc-52-away-from-static-ids/3931/1